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The Real Time Computer Complex : The Real Time Computer Complex 
(RTCC) at Houston, Texas, is the NASA's ground support computing and 
data processing center for manned space flight. RTCC's primary respon¬ 
sibility is to provide real time information for mission control. But this . 
role entails many additional supporting tasks: constant program system 
development; training of personnel for simulation exercises and flight 
support; providing and operating computer-driven diagnostics for RTCC 
and Mission Control Center equipment. 

The RTCC Programming Systems : In general, each NASA mission, e. g. , 
GT-6, GT-7, etc., requires three real time systems. The Mission 
Operational System (MOS) has approximately three quarters of a million 
words of instructions and data, with a mission-to-mission carryover 
of about iO per cent. The tracking network simulation system (DYNAMIC) 
has about a hundred thousand words. The Simulation Checkout and Train¬ 
ing System (SCATS) has about two hundred thousand words. The two 
simulation systems have a carryover of about 65 per cent. 

Several other real time systems are available for miscellaneous 
support functions. A .] 

All of the RTCC real time systems operate under a common Executive: 
Control Program. However each system requires a dedicated computer -; ' 
system. : 

Approximately one-half of the mathematics and related logic of the 
real time systems is represented by FORTRAN code. If more computer 
capacity were available, or if the compiler-included penalty in object 
efficiency could be eliminated, more problem oriented code would be used* 

/V'- ■■ 

Missions become increasingly complex. The initial S/360 RTCC systems 
may be expected to double the sixes given here. 
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All <*t the* program proparation and some ot' the program and sub¬ 
system testing us supported by a modified version of IBSYS/ IBJOB. 
Individual programs (now called .oad modules) correspond to IBJOBs. 

These are collected by an extensively-modified IBLDR-Editor which 
produces the real time system tapes. y; f 

The RTCC 7094 Hardware Configuration : The current RTCC hardware 
configuration us illustrated functionally in Figure 1, The System Selector 
Unit (S.SU) is a plug board switch box and provides the linkage between 
the real-time I/O devices and the 7094 systems. The SSU connections 
endow a computer system with a functional assignment. The SSU is 
transparent (non-programmable) to the computer system and, while 
some limited dynamic function exchange is possible, the SSU is essentially 
a static device. No condescension is intended. The SSU has served its 
intended function well. 

Each of the five computing systems is an identical, independent 
7094-11 system. Each system has a modified relocate and protect 
feature that permits direct addressing throughout the 65K of primary 
memory. The 2361-Large Capacity Storage (LCS), provides a relatively 
large (524K words), fast (250K words/second) auxiliary storage acces¬ 
sible through a 7044-type data channel (7286). Output to the television 
display system is transmitted through the SSU by direct data on a 7286 
channel. Other real time information is transmitted through the SSU 
over subchannels of the 7281 Data Communications Channel. 

For mission support, the NASA reliability requirements are satisfied 
by fully duplexing systems: the mission computer has an immediate backup 
always available. 

Some Considerations of the Current R TCC : The major problems of the 
current R TCC hardware a re gene rally the limitations of the 7094 systemao*- 
no expandability. The total system reflects these limitations. Within the v 



r.iniiuinj; nivironment, dyn* in) 1 i $i uinanagnnrat and d<*\ u e 
allocation arc, of course, provided, as is secondary storage allocation, : 

s 

but a trui‘ resource sharing a la multitusking/multijobbing was ignored 
in the preliminary RTCC design sessions of early 1963 for a number of 
reasons. Primarily, IB JOB could not support it. Ultimately, two soft- 
ware systems resulted with alrm st no interface at all. ' : IBJOB was modified 
to produ< e a self-contained, self-loading real time system. Because eaifly 
in the R TCC development the real time system was unavailable and because 
of the improved efficiency of an IB JOB environment for limited testing, 
an Executive simulator running under IBJOB was produced. 

One of the more notable systems achievements was the development 
of the master libraries. IBLDR, primarily, and to some degree other 
components of IBJOIi/IBSYS were modified to produce an d handle both 
jajuoar y and sy mbolic maste r files. These permitted the programmer to 
construct real time tapes for execution by symbolic alters to cataloged 
source programs or by combining binary decks to produce any number of 
load modules. Today, some limitations are obvious--the lack of direct 
access storage and limited expandability, but at that time the results 
gave a significant improvement over any previous methods for building 
and controlling large systems. (Incidentally, the need for a similar facility 
was apparently overlooked by the OS/360 designers though not by the OS/360 
implementers who developed a nearly identical function as part of the A TP . 2 
system.) T ][{ v-.. : 

The RTCC S/ i 60 Configuration: Figure 3 illustrates the RTCC configuration 
which will be operational in 1967. The rigid independence of each 7094 
system has been softened by removing from the individual computers the 
control units and devices. Between the channels and, the control units, 
the 2911 Remote Control Switches provide access to pooled devices. The ' ‘ ; 
2911 switches significantly enhance reliability by permitting alternate 
paths to all real time critical devites; the 2911 switches eliminate plug hoard 
connections permitting automatic reconfiguration, 
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f^ai )i < uniputer .ystcm is i<i»*nt.u ;il; Mpflrl 7SJ, with ( wn«rru'g.thy1i* 
priv.iie 1/7S ruid om*-megabyte \A'.S shared among all systems, Kach 
system has a storage channel' mainly for transmission between LOS and 

•S'' . ; . , 

primary storage, a multiplexor channel with selector subchannels for 
tapes, data Cells, unit record devices and real time transmissions, and : 
a pair of selector subchannels for drums and disks. (Originally, no 
computer was to have private, non-pooled direct access devices. This 
may be impractical, at least for the near future;.) 

Each c omputer is equipped with a -32-bit CPU; register for arbitrary 
interval tuner interrupts with 11;-microsecond precision. The timer 
requires no storage cycles to maintain time. The NASA, time standard, 
GMT, can be read directly into core storage, also with 10-microsecond 
precision. 

The computer systems may communicate via the direct control 
feature, by the shared L.CS, and with reduced responsiveness via shared 
storage devices beyond the 2911 switches. 

Clearly, RTCC has a computer facility that permits each computer 
to operate as an independent system by assigning the pooled devices. In 
the interim period between the first RTCC S/360 installation and sometime 
in 1967, Model 75s will coexist with 7094s as stand-alone computers, 
simple replacements for current computers. How the collective Model 75s 
will operate as multiprocessors in 1967 is currently in the planning stage. 
One fundamental consideration in these plans is the desire to retain suffi¬ 
cient compatibility with OS/360 as it evolves. ' 

Commitment to OS/ 360 for RTCC : With the advent of preliminary OS/360 
literature, RTCC began to evaluate the concepts and facilities of the futur e 
operating system. I'he initial survey concluded that OS/360, in comparison 
with the contemporary 7094 real time Executive, would increase overhead 
by an unknown factor. Most of the basic functions appeared to be there.- 



Bat, more important by far, whatever problems created by trying to 
live with OS/.$60 in real time, the alternatives were unthinkable, A 
separate, but equal, total operating system for KTCC functions could 
neither be justified nor funded. In addition, as real time support require* 
ments (inc luding the enormous number of simulations) keep growing, the 
inability to apply excess resources to program and system development 
would become ever more acute. The present dichotomy between the 
environments of the real time system generator (IBJOB) and the real 
time system should not be perpetuated through another technological 
generation. 

The very specialized application at KTCC precludes complete coverage 
by any generalized operating system even one with the basic multiprogramming 
tools. The optimum compromise* would preserve the maximum usefulness 
of the OS/360 control program at minimum cost. The end result of the 
RTCC effort would be an operating system which would provide all 
facilities of OS/360 to the normal, or default, user. However, for the 7 
real time user, standard OS/360 features w,ould be augmented in some 
cases and restricted in others. One control program would support these , 
two modes of operation concurrently, with the execution mode as an m 
attribute of the job step. * 

Problems Peculiar to the RTCC Project : The most obvious area where 
local systems programming would be required is the real time input-output 
devices. No standard OS/36Q ac cess method is expected to drive the 
television system, the plotboard, or the other devices of the Mission 7 . 77 - 
Control Center. In fact, while some real time devices could be handled 
in normal data management fashion, most could not. In usage, most ' : 
RTCC real time devices are handled less like standard data set volumes 7 ;7 

than the c onsole typewriter in OS'' 360. Instead of one user who controls 
the data set., there a re many users who send information to the devices. 

___________ 

Some statistic s from the 709*4 mission support system may prove interesting: 

Wliile launch phase processing has periods of extended 100% CPU utiliration, 

the orbit phase uses approximately 15%. GT-7 combined less than 10 min¬ 
utes of launch with two weeks of orbit. 
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A number of other functions are less obvious, perhaps but critical 
to the RTCC. These functions are provided by the current 7094 control 
program. Some of the functions r.re basically development tools with 
little meaning in real time support; they are, nonetheless, necessary: 

© fail-soft facilities are r ecessary. These may require closing 
of input lines and imply a greater monitoring capability than 
that normally given to the control program. Practical tools 
must be prov ided for tin.* problem program to define the 
direction selective work elimination should take. 

• total failure (collapse) of the problem program system may be 
necessary for debugging, i. e. , to find an elusive bug, but cannot 
be permitted in real time support. The control program must . 
recognize which condition applies, y , 

• a restart procedure must include all the elements needed for 
real time, 

© a standard, logging facility is necessary to record transmissions 
across the real time interface. I 

e the control program must recognize the switchover condition, 

in which the primary and backup computers interchange functions* 
m specialized forms of time c ontrol are essential for efficient testing 
These include adjusting time forward or backward and the ability 
to compress out idle time (a 90-minute orbit can witft this feature 

be run in less than 20 minutes). J 

■ ' [ ■ ..vT • ■' u .-. T ■ ' 

« simulated real time inpj.il and output device support must be 

provided to accomplish off line checkout of problem programs. 
Automatic handling of simulated data has been a mainstay in 
RTCC debugging: entire applications systems can be developed 
without recourse to any real time equipment other than a clock. 
Recause'this feature is part of the control program, all 
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applications systrms' ciii use the strvh r, Ami nmro important, 
no change n* *‘<i be mad«- to the applica t urns programs 'when 
taken from the simulated data environment to real time support. 
RTCChs Requirements and OS/360 Solutions : The nature of RTCC real 
time systems significantly differs from batch or job shop processing and 
from many other real time applications. Typically, real timedata 
produces distinctly repetitious processing cycles in the program system. 
The duration of the cycle may vary from several hundred milliseconds to 
many seconds. Frequently, a number of processing cycles of varying 
duration exist concurrently. Superimposed upon, and continuously 
distorting the cyclic processing is the support for the button pusher, the 
i NASA flight controllers (and if RTCC is anything, it is a man-machine 
communications system). 

In this environment the geography of core storage is constantly 
changing. Also, in this environment, the price of finding and loading 
programs often measures the response of the system. The performance 
of core allocation, for example, must be measured not only in its utili¬ 
zation of core storage, but in the overhead extracted for the service. The 
effect of cyclic processing on system design will be shown later. 

Because of the restrictions in interjob communications, each 7094 
real time system would have to be translated into a single OS/ 3.60 jobstep. 
This preserves a logical integrity, but introduces some problems. Pro¬ 
tection keys and roll in / rollout as jobstep-depemlent functions would not 
suffice. 

Within any OS/dd) jobstep, the basic logic is reflected \n a pyramid.!? 
hierarchy of subtasks. At t lie top oi the pyramid is the primary subta^K. 
This is the subtask initialed by tie* control program to start the job stop. \ 
RTCC began building their real time systems on the 7094 with a type of 
'pyramidal hierarchy of control. Kxperienee soon led to the following 
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conclusion; depends ure - - 1 he mam program with sub routine approach-- 
is invaimble for relatively small functions. As si /e and ioinplexity 
increase, the difficulties in coni muni cat ion and control increase geo¬ 
metrically with respect to the number of control levels* RTCC resolved 
this problem on the 7094 systems by expanding indefinitely the number 
of tasks which might share the highest control level (though not necessarily 
priority). The identical approach appeared feasible within (or almost 
within) tin- context, of OS/ V00 design. 

Modification 1. Inde pendent T a sk s: The logical c onc lusion was a new 
type of task--an independent task. A number of attributes were defined 
to distinguish an independent task from a conventional task. An indepen¬ 
dent has a name, which is the name* of a task and not the name of a 
program initiating the task. An independent task may have subtasks, but 
is not a subta.sk of any other task. An independent task has a unique 
protect key, shared with any related subtasks. An independent task may 
return from its highest loved to the control program without abandoning 
all acquired resources, notably subpool storage. This defines a new 
condition of a task, unique to independent tasks, the condition of being dor¬ 
mant. This is the normal state of an independent task which handles 
c 

eyelid processing when the cyc le is temporarilv idle. 

The name of the independent task is in effect a serially reusable 
resource. Once a named task has initiated processing, that task may 
not again be initiated until it has relinquished control from its highest 
control level. ' 

An independent task cannot be attached as are subtasks; an indepen¬ 
dent task is initiated as soon as priority permits after a work entry has 
been placed in the queue for the ,task. The dimensional characteristic* 
of this queue provides a handle for introducing fail-soft techniques. For 
instance', an independent task processing cyclic input may permit no 



entries t. • be vived during a cy* • e. Backlogged work ncvr r » hokes tin-, 
task. K.\( <'S^ data m discarded. Certainly, imi all data i > d. i sea rdabb •. 

But mudi is. And when a system is in danger of severe overload, rruu h 
more is. 

Finally, an independent task’s priority is an attribute of the work 
queue entry. This priority need not be related to the priority of the 
entry’s originator. 

With priority, R fCC requires the fac ility to define and modify simply 
all of the priorities of a system. 'This is considered an analyst’s problem 
and should be independent of the code using tin* priorities. A solution 
probably will result, in symbolic priorities being used in the code and 
tables provided to translate the symbols into values. Dependent tasks, 
or subtasks, use standard OS/ ibO priorities. For any family of tasks, 

an independent task must exist at the highest control level and its priority 
applies to subtasks in the normal OS/360 manner. The independent task 
is the building block for the RTOC real time systems. In fact, in the 
real time mode, a subtask literally can’t get started without one. 

The independent, task- -once, defined --prov ides the necessary facility 
for data routing, a facility of the current 709*4 control program. 

Modification l . Data Rout ing : On the current 7094 systems, real time 
input arrives in many cases multiplexed by message on a physical line. 

The messages which share the' line need not be logically related and often 
are not, Ea< h problem program to receive real time input defines selection 
c riteria winc h can identify uniquely the messages required by that problem 
program. When a real time input message arrives, the control program 
examines the* selection criteria to determine which, it any. program^ ore 
to receive the: messages. Additional facilities available are: 



® buff r r mg -accumulu t»- five messages tjoforr plaimg an entry 

1M the fjUCli'*, '' 

o 1 1 me - r el a ted no s s - pi<»« <• .m entry in the queue e\ery ,6 

seconds with as many messages as have arrived, even if none 
have, M 

© time out--” place an entry in the queue after five messages or 
.5 seconds, whichever occurs first." 

For the RTCC modified OS/ $60 system, only independent tasks may 
receive routed data. Consequently, the control program is simply another 
originator inserting an entry m independent task’s work queue. 

Control of real time input is maintained by the control program. An 
independent task’s name is specified with the routing information. The 
task is involved only when work has been identified for it. 

Modification 5, . Data Tables: An additional requirement exists for a 
simple, efficient method of handling relatively small data sets. This was 
resolved by slight modifications to the partitioned data set facility. 

Libraries for real time would consist of programs and data tables as 
members. Like the programs, the data tables would be dimensionally 
static during the jobstep to permit tn-place updating. Data tables could 
contain initial values or zeros prior to.execution of the jobstep. Slight 
modifications to the basic LOAD and DELETE macro-instructions would 
permit handling data tables as logical extensions of subpool storage, shared 
between independent tasks. Write and read facilities would permit using 
data tables with simple (basically HDAM) accessing without DCBs, OPENs, 
DD statements and the like. Locking facilities would resolve by seriali¬ 
zation any conflicts in concurrent usage. 

The 1 ibraries--data tables and programs--would have received auto¬ 
matic servicing by virtue of an R-TLIB statement, essentially lifted from 
the JOBLiB concept. 
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M i s i el ia11 * ■ on n \'lo<i) ! ; » a 1 1 on s to ( sMb(); After the "tuiiujr" i nod 1f1 ca t mn s 
to OS/.56o already specified, R’lCCVs other plans am somewhat anti- 
climatical. Independent tasks, data routing and data tables are the 
essentials. However, other problems must be solved. 

Enqueue and dequeue facilities need to be provided where the resource 
is represented by a name, rather than a core location since independent 
tasks do not share core locations. 

The c ore allocation algonth n will have to be modified for R FCC. 

The cyclic nature of the processing affects the choice of which program 
to overlay when room is needed. 

Roll i n/rollout must be solved another way. RTCC's experience with 
rollout has been that recovery from it is a sometimes thing with low 
probabilities. On the 7094 systems it was simpler to prevent rollout 
than to recover. 

A facility for handling sourc e and text libraries and using these in 
normal development work similar to the 7094 facility (and A TP) is being 
developed. 

Two copies of the square root, cosine, etc. , subroutines are too many; 
a LINK to these is tooinefficient. A compromise is being developed. > 

A method of handling applications systems parameters is needed to 
allow multiple programs to reference* the correct current value of critical 
parameters, for example, capsule weight. 

Directories, or subsets of directories, will be maintained in core to 
reduce the time for program fetch. 

Undoubtedly, other problems are waiting to be discovered. We have 
only begun. But RTCC is confident that a highly responsive real time 
system and OS/360 < an--more or less compatibly--live together and like it. 
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